Stop forwarding caller-supplied bearers, and stop advertising the wikis' issuers - #518

Closes #504.

With the hosted OAuth proxy disabled, an Authorization header was forwarded to MediaWiki verbatim, and /.well-known/oauth-protected-resource named the wikis' own authorization servers. Together those steered a client into minting a token at the wiki and presenting it here — the shape MCP forbids, since a server must not accept tokens that were not issued for it.

What changes

Forwarding requires MCP_ALLOW_BEARER_PASSTHROUGH=true, is deprecated, and warns at startup. Without it a request carrying a bearer is refused 401 rather than served: ignoring the header would run the request anonymously or as a configured identity while the caller believed it was acting as itself.

Nothing advertises the wikis' authorization servers any more. With the proxy off, /.well-known/oauth-protected-resource answers 404, and list-wikis omits each wiki's authorizationServer — it named where to mint a token this server now refuses. The 401 challenge carries resource_metadata only when that document exists; otherwise it is a bare Bearer challenge, which RFC 6750 admits.

A deployment that can no longer serve anything says so: the server warns at startup when a wiki requires a signed-in user and neither hosted sign-in nor forwarding can provide one. A private default wiki is stranded even with static credentials, because the challenge precedes credential resolution. The tool-layer error names the operator's action rather than asking for a token the transport would refuse.

Two exported signatures tightened, in both cases because omitting the argument now means something dangerous rather than something useful: buildProtectedResource takes a required authorizationServers, and createOAuthProtectedResourceHandler a required getProxyConfig (pass () => null for no proxy).

What a reviewer should weigh

The refusal is deliberately not keyed on oauth2ClientId. That option describes how this server runs browser sign-in, not whether the wiki accepts bearers — any wiki with Extension:OAuth does. Keying on it would keep forwarding tokens on exactly the documented public read-only and manual-token shapes. A test covers that configuration.

The advertisement is removed even under the opt-in. Forwarding is documented for callers that already hold a token, so they need no discovery, and restoring it would reinstate the steering this closes.

Client impact is narrower than the diff

No client-negotiation surface is touched: register.ts, cimd.ts, redirectPolicy.ts and asMetadata.ts are unchanged, so hosted-sign-in deployments behave identically — discovery, dynamic registration and CIMD all as before.

UpstreamAsMetadata carries no registration_endpoint, so MediaWiki offers no dynamic client registration and a client that discovered a wiki's issuer could never self-register. The advertisement was never a zero-install path. The one real break is manual-token setup — the population this deprecation exists to migrate.

Verification

Full suite 1,696 green; typecheck, lint (zero warnings) and format clean.

Confirmed end to end against a real MediaWiki 1.43.6 wiki, with a request tap between this server and the wiki recording the Authorization header of everything we send upstream.

Anonymous reads return real page content and do reach the wiki in every column, so the "nothing reaches the wiki" cells are genuine negatives rather than a probe that stopped working. A private wiki that can be signed into by no route warns at startup and names the setting to change. The refusal was also exercised against a configuration with no oauth2ClientId anywhere, the shape the gate described above would have missed.

Each behaviour change is mutation-bound: reverting the refusal, restoring the advertisement, ungating the tokenless challenge, or making the challenge always advertise each fail a test.

Open

The deprecation says forwarding will be removed without naming a release.

src/runtime/authShape.ts reads process.env through a default parameter rather than the explicit injection evaluateBearerGuard uses. Threading an environment through the per-request call sites would be invasive for a cosmetic gain, so it is tested directly instead.